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Sir or Madam; 

I, Stephen Appling, hereby declare that: 

1 . I am the sole inventor of U.S. Patent Application Serial No. 09/747.366 ("'366 
application") referenced above. 

2. The present application describes and claims methods for updating objects contained 
within a web page by providing an invisible frame on the web page that is configured to 
periodically request updated data from a server and cause an object in the web page to be 
updated based on the data acquired from the server. 

3. Ihave reviewed Heidingsfeld et al., U.S. Patent No. 6,823.359, which was cited in the 
Office Actions mailed June 2. 2005, December 23. 2005, January 3, 2007, and July 23, 2007. m 
connection with the '366 application. I understand that Heidingsfeld et al. has an effective 
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prior art date of November 21, 2000. 

4. This declaration and the attached documents establish that I conceived and reduced to 
practice the system and method for updating objects contained within a webpage defined by 
pending claims 1-5, 7-11. 13 and 16-21 of the *366 application prior to November 21, 2000, 
The documents are described below. 

5. Exhibit 1 is an initial design document entitled "Greenhouse UI Architecture" in which 
the concept of updating objects contained within a web page using an invisible in-line fmne is 
discussed. See Exhibit A, § 3. 1 . Exhibit 1 is an internal document that does not contain a date 
in the body of the document. However, the electronic file system on which it was created 
tracks both the date of creation, as well as the date the document was last modified. Exhibit 1 
was last modified on January 25, 1999. Therefore, the content of Exhibit 1 that relates to the 
invention claimed in the *366 application was created at least as early as January 25, 1999. 

6. Exhibit 2 is an advertisement &om the January 2000 ASHRAE Journal anouncmg the 
release of a new product to be demonstrated at the AHR Expo on February 7 and 8 of 20(K). 

7. Exhibit 3 is an advertisement from die February 2000 ASHRAE Journal describing and 
showing the jwroduct, *WebCTRL", demonstrated at the AHR Expo on February 7 and 8 of 
2000. 

8. WebCTRL is a web based extension to building control system software, which 
provides an interactive graphical user interface to building operational and comfort conditions 
through a standard web browser. Built into WebCTRL is an embodiment of the invention 
claimed in the '366 application. Specifically, WebCTRL include the functions to dynamically 
update objects in a web page using an invisible frame configured to periodically request 
information, such as sensor readings from a component of a building HVAC system, from a 
server and update the object with the information requested from the server. 

9. A functioning prototype of WebCTRL, including the components for updating objects 
in a web page, was demonstrated at the AHR Expo on February 7 and 8 of 2000. 

1 0. Although an embodiment of the invention claimed in the '366 application was included 
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in the demonstration of WebCTRL at the AHR Expo, the invention was not publicly disclosed. 
The functions for dynamically updating objects contained within a web page were not publicly 
disclosed at the AHR Expo, because it was only the results, i.e. objects on the page being 
updated, which were discemable dirough the public demonstration of the WebCTRL product. 
The functions or components of the WebCTRL product that cause the objects to update and 
that represent an embodiment of the invention claimed in the *366 application ww^ not 
disclosed, but were present in the WebCTRL product and did operate as intended 
11. As evidenced by the design document of Exhibit 1 and the advertisements of Exhibits 2 

and 3, the invention claimed in the *366 application was conceived and reduced to practice at 
least as early as February 7, 2000, which is prior to the November 21, 2000 prior art date of 
Heidingsfeld et al. 



statements made on information and belief are believed to be true; and further that these statement 
were made with the knowledge that willful false statements and the like so made are punishable by 
fine or imprisonment, or both, under 18 U.S.C. 1001, and that such willful false statements may 
jeopardize the validity of the q)pIication ot any patent issuing thereon. 



I declare that all statements made herein of my own knowledge are true and that all 
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Exhibit 1 



Greenhouse UI Architecture 



1- Overall 

Almost all of the client side pages will rely on an ALC JavaScript library to standardize 
operations like positioning, dynamic content loading, and dynamic content generation on 
the client s ide. This will allow us to do this in a cross browser way if we decide to. See 
ilBUMIBlg^ for the JavaScript Library requirements. 



We also need a single point of entry that handles login and establishes session 
information. 

Need to develop: 

1) Login Screen 

2) Login Servlet 

3) JavaScript Library that includes: 

a) Creation of screen elements from JS Objects (both at load time and 
while running) 

b) Dynamic update of screen element content. 

c) Cross browser screen element style access. 

d) JS Behaviors (motion, click handlers, onLoad handler chains) 

e) Naming and Locating (both screen elements and JSObjects) 

2. Navigation Pane 

The Navigation Pane contains three active areas: the Show Menu, the Tree, and the 
Navigation Tabs. The operation of this pane is very consistent for all four tabs (almost 
identical for Geographic and Network). This should be one page where the tree control is 
placed into different states (views) by the selection of navigation tabs. The selection of 
navigation tabs should not cause the left pane to reload. This makes it easier for the tree 
to keep state information when switching tabs, then back again. The tree should only get 
as much information as it needs from the server to display the current level (perhaps 
some optimization later to get the next one?). The tree should retain information from a 
collapsed branch that was previously expanded. It should also be able to support some 
type of reset function. The Tree control will probably be a Java Applet (it can be done in 
JavaScript, but probably isn't worth it). We should do some more testing on LiveConnect 
before deciding this finally. Try LiveConnect on several IE platforms and on NS under 
Linux, Should the tree poll the core for updates to already downloaded information? We 
won't support real time editing of the tree in version 1 .0, but at least the icons can 
change. Perhaps this refresh could be triggered "manually" when a tree altering 
operation is performed. We will also need a servlet to look up the tree information on the 
server. The servlet should respond to queries with tree content information formatted in 
XML. When a selection is made in the tree, the tree control should navigate the action 
pane to the appropriate URL. 

The XML tree information needs to contain a hierarchical tree of nodes where each node 
has: 



1) Unique ID 

2) Leaves marked. 

3) Icon URL for collapsed and expanded state (do these need to be different for 
some nodes?) 

4) List of associated icons w/ icon GUIDs and icon URLs 

5) Node navigation URL 

6) Node Text 

The tree control applet must keep a set of tree information for each of the four tabs. 



In summary, the navigation pane consists of a single normal HTML page populated with 
three major elements. 

Need to develop: 

1) A good tree control applet. 

2) A JavaScript Drop down menu that can send control information to the 
tree. 

3) A JavaScript Tabset that can send control information to the tree. 

4) A Single HTML page containing the above elements which 
dynamically sizes the tree to fill the appropriate space. 

5) A Treelnfo servlet. 



3- Action Pane 

For the action pane, the content of each tab is very different. Selection of different tabs 
on this page should navigate the action pane to a new page. The currendy selected tab 
should also be stored (in a JavaScript object in the nav pane) so that the selected tab may 
stay selected when a new node is selected. The action pane will be a single frame 
(initially targeted to a servlet). The tabset at the top and any border will be generated by 
the action pane servlet - the remainder of the page should be obtained using JSP 
chaining. The action pane servlet should take as a parameter, the id of the selected node 
and store it in the session object. The tabset will always include the same number of tabs 
- inactive tabs for a particular node will be grayed out. 

Need to develop: 

1) An ActionPane servlet which can dynamically generate the appropriate 
tabset. 

2) Architecture to chain JSP (or another servlet) from the servlet to get 
the contents. 

3.1. Graphics 

The target URL for the graphics content should actually be another servlet, not a JSP 
page. This servlet should find the appropriate page for the node. If a custom graphics 
page is indicated in the database, it will simply chain to it, otherwise it will chain to the 
appropriate object control JSP or child list JSP. All of the graphics pages will contain 
dynamic content which will be updated separately from the main page via a hidden 



(inline) frame that just evaluates JavaScript. This frame will be pointed at an expression 
evaluation servlet that returns JavaScript. The expressions to be should be read from a 
server side XML conditions file associated with that graphics page. The selected node's 
ID should be read out of the session object. 



Need to develop: 

1) Expression evaluation servlet 

2) Graphics page template 

3) Dynamic Color Server (for thermographic floorplans) 

4) Collection of Dynamic elements to place on page (JavaScript and 
Fusion components) 

a) Text (Content, Style, Color) 

b) Graphics (Dynamic Source) 

c) Animation (Start / Stop) 

d) Dynamic Color Floorplans 

Need to develop JSPs and controls for the following default object pages: 
(each of these may have different flavors for different units) 

1) Analog Input 

2) Analog Output 

3) Analog Value 

4) Binary Input 

5) Binary Output 

6) Binary Value 

7) Multi-State Input 

8) Multi-State Output 

9) Multi-State Value 

10) Calendar 

11) Schedule 

3.2. Properties 



The property page is a JSP page generated by Eikon at design time for each function 
block. The page should utilize JSPs JavaBean access to get the information for all of the 
variable content. All of the data access for the page should be optimized into one web- 
server to core CORBA call. Properties are displayed using JavaScript library functions 
that allow a non-form look and feel. 

Customization idea - start with pre-made JSPs for all microblocks. Each JSP accepts a 
few standard parameters such as "name". Basic Eikon customization is just to set design 
time parameters which are then generated as a part of the resulting JSP files for each 
GFB. For a more customized microblock property page, the system should copy (and 
uniquely name) the default microblock JSP page and start the HTML editor 



(Dreamweaver?) with the new file. We should develop some DW extensions to allow 
easy access to the properties. 

Need to develop: 

1) JavaBeans to look up values (including lookup synchronization) 

2) JavaScript library of property components. 

3) Property JSPs for all microblocks. 

3.3. Schedule 

The scheduling tab will largely be an application written in JavaScript. All of the user 
interaction code will run in JavaScript on the client. However, any code for database or 
core access should be done in a servlet or a server side JavaBean. The scheduling tab 
will point to a frameset page. The top frame will contain a JSP with data generated on 
the server. This frame will reload to get new data. The bottom right frame (calendar) 
will probably be a Java Applet. We should look for some good existing calendar applets 
(commercial or public domain). The editing / results page will be another JSP page. 
Schedule evaluation will be done in the core and accessed through a server side 
JavaBean. Editing / display of the time lines will be done with either JavaScript or 
several Java Applets. 



Need to develop: 

1) JavaBean to build list of applicable schedules for a level. 

2) Schedule Frameset 

3) Top JSP page w/ JavaScript 

4) Calendar Control 

5) Timeline Edit Control 

6) Edit / Display JSP page w/ JavaScript Logic 

3.4- Events 



3-5- Reporting Actions 



3.6. Trends 

The trending tab will consist of two JSP pages, one for configuration and one for 
viewing. The images on the viewing tab will come from a TrendView servlet, which 
may be referenced in other locations as well. The method of editing the trend view 
parameters has not been determined. 



Need to develop: 

1) 

2) 



Two Trend JSPs 
Trend View Servlet 
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See how you can have true operational 
fr©edorn wtai WebCTRLT, our new 
browser-based remote access building 
control software. See how our Java- 
based, web-enabled SechnoiogiTtets'' " 
you run on nnany different operating 
systerr^. See how WebCTRUs 100% 
open architecture and native support 
for BACn i^ give you flexIbiJity like 

you've never had before. 
Contact your Automated 
™ Logfc Partner or visit us at 
www«si(uifi©ma.'6<sdtogic,corin; We'll 
make sure you^n get more than Just a 
remote explanation! 
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